F5 and Cisco ACI Essentials: Automate, automate, automate! – Cisco Blogs

This blog is a joint collaboration between Ravi Balakrishnan (Cisco) and Payal Singh (F5)

This article will focus on automation support by BIG-IP and Cisco ACI and how automation tools, specifically Ansible, can be used to automate different use cases. Before getting into the weeds let’s discuss and understand BIG-IP’s and Cisco ACI’s automation strategies.

BIG-IP automation strategy

BIG-IP automation strategy is simple-abstract as much complexity as possible from the user, give an easy button to the user to deploy their BIG-IP configuration. This could honestly mean different methods to different people; some prefer sending a single API call to perform one action (A one-to-one mapping between your API<->Configuration).

Others prefer a more declarative approach where one API call performs multiple actions, basically a one-to -many mapping between your API(1)<->Configuration(N). Learn about the different options in the Automation and orchestration toolchain.

Cisco ACI automation strategy

Cisco Application Policy Infrastructure Controller (APIC) is the network controller for the ACI fabric. APIC is the unified point of automation and management for the Cisco ACI fabric, policy enforcement, and health monitoring. The Cisco ACI programmability model provides complete programmatic access using APIC. Learn more at the Cisco DevNet Application Centric Infrastructure site.

Automation tools

There are a lot of automation tools that are being talked for network automation BUT the one that comes up in every customer conversation is Ansible. Its simplicity, maturity and community adoption has made it very popular. In this article we are going to focus on using Ansible to automate a service discovery use case.

Use Case: Dynamic EP attach/detach

Let’s take an example of a simple http web service being made highly available and secure using the BIG-IP Virtual IP address. This web service has a bunch of backend web servers hosting the application, the IP of this web servers is configured on the BIG-IP as pool members. These same web server IP’s are learned as endpoints in the ACI fabric and are part of an End Point Group (EPG) on the APIC. Hence there is a logical mapping between a EPG on APIC and a pool on the BIG-IP.

Now if the application is adding or deleting web servers that is hosting the application maybe to save cost or maybe to deal with increase/decrease of traffic, what happens is that the web server IP will be automatically learned/unlearned on APIC. BUT an admin will still have to add/remove that web server IP from the pool on BIG-IP. This can be a burden on the network admin specially if this happens very often. Here is where automation can help and let’s look at how in the next section

More details on the use case can be found on dev/central, F5 & Cisco ACI Essentials

Automation of Use Case: Dynamic EP attach/detach

Automation can be achieved by using Ansible and Ansible tower where API calls are made directly to the BIG-IP. Another option it to use the F5 ACI ServiceCenter (a native F5 ACI integration) to automate this particular use case.

Ansible and Ansible Tower

Using this method of automation separate API calls are made directly to the ACI and the BIG-IP. Learn more about Ansible and Ansible Tower

Sample playbook to perform the addition and deletion of pool members to a BIG-IP pool based on
members in a particular EPG. The mapping of pool to EPG is provided as input to the playbook.

Ansible tower’s scheduling feature can be used to schedule this playbook to be run every minute, every hour or once per day based on how often an application is expected to change and how important is it for the configuration on both the Cisco ACI and the BIG-IP to be in sync.

F5 ACI ServiceCenter

The F5 ACI ServiceCenter is installed on the APIC controller. Here automation can be used to create the initial EPG to Pool mapping. Once the mapping is created the F5 ACI ServiceCenter handles the dynamic sizing of pools based on events generated by APIC. Events are generated when a server is learned/unlearned on an EPG which is what the F5 ACI ServiceCenter listens to and accordingly adds or removes pool members from the BIG-IP.  Learn more about the integration: F5 ACI ServiceCenter

Sample playbook to deploy the mapping configuration on the BIG-IP through the F5 ACI ServiceCenter

After deploying this configuration, adding/deleting pool members and making sure the configuration is in sync is the responsibility of the F5 ACI ServiceCenter.

Takeaways

Both methods are highly effective and usable. The choice of which one to use comes down to the operational model in your environment. Some pros and cons to help made the decision on which platform to use for automation.

Ansible Tower

Pros

• • No dependency on any other tools
  • Fits in better with bigger company automation strategy to use Ansible for ALL network automation

Cons

• • Have to manage playbook execution and scheduling using Ansible Tower
  • If more logic is needed besides what’s described above playbooks will have to be written and maintained
  • Execution of playbook is based on scheduling and is not event driven

F5 ACI ServiceCenter

Pros

• • Only pool-epg mapping has to be deployed using automation, rest all is handled by the application
  • User interface to view pool member to EPG mapping once deployed and view discrepancies if any
  • Limited automation knowledge is needed, heavy lifting is being done by the application
  • Dynamically adding/deleting pool members is event driven, as members are learned/unlearned by the F5 ACI ServiceCenter an action is taken

Cons

• • Another tool is required
  • Customization of pool to EPG mapping is not present. Only one-to-one EPG to pool mapping is present.

References

Share: